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SUMMARY 

The  tasks  involved  in  developing  a  fault  diagnosis  expert  system  for  a  gas  turbine  engine  are 
examined.  Particular  attention  is  given  to  the  options  available  to  maximise  the  quality  of 
the  advice  given  by  the  expert  system.  All  phases  of  system  development  from  knowledge 
acquisition,  through  to  system  support  are  covered.  A  general  example  of  diagnosis  by 
engineering  analysis  is  given  to  demonstrate  the  concepts  involved.  Using  acquired 
knowledge,  a  limited  qualitative  fault  model  of  the  TF30-P3  gas  turbine  engine  afterburner 
has  been  developed,  and  application  to  some  fault  case  examples  is  described. 
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I.  [INTRODUCTION 

The  use  of  expert  system  technology  to  provide  aircraft  engine  maintenance 
personnel  with  an  expert  advisor  has  the  potential  to  raise  overall  fault  diagnosis 
performance.  The  processes  involved  in  creating  an  expert  system  to  perform  this 
role  are  now  quite  well  developed.  The  success  of  the  IFDIS  concept  demonstrator 
at  proving  the  concept  of  providing  an  acceptable  advisor  for  troubleshooting  is  an 
example  of  this  fact. 

The  task  at  hand  now  is  to  ensure  that, as  these  expert  systems  pass  from 
prototype  and  concept  demonstrator  phases  into  systems  that  are  implemented  on 
line  in  the  maintenance  environment,  the  advice  given  becomes  worthy  of  the 
"Expert  Advisor"  name. 

This  document  examines  the  ways  in  which  the  knowledge  behind  the  advice 
given  can  be  of  the  highest  attainable  quality.  Broadly  the  recommended  approach  is 
to  aquire  integrated  experiential  and  engineering  knowledge,  and  apply  this 
knowledge  to  the  causal  justification  of  the  expert  system  rules  and  the  development 
of  a  qualitative  fault  model. 

The  three  concepts  given  above  of  acquiring  integrated  experiential  and 
engineering  knowledge,  causal  justification  of  rules,  and  qualitative  fault  modeling 
are  central  to  overcoming  the  problem  of  producing  an  expert  system  which 
performs  with  a  high  degree  of  integrity  and  veracity.  These  qualities  are  crucial  to 
the  success  of  a  diagnostic  expert  system.  As  such,  investigative  effort  into  these 
fields  is  seen  as  a  worthwhile  exercise. 


2.  INTERACTIVE  FAULT  DIAGNOSIS  AND  ISOLATION  SYSTEM. 

The  IFDIS  project  utilises  expert  system  techniques  in  the  field  of  jet  engine 
diagnostics.  A  concept  demonstrator  has  been  developed  which  is  an  expert  advisor 
for  troubleshooting  faults  in  the  afterburner  of  the  TF30  jet  engine.  Tlie  prrblem 
domain  dealt  with  in  the  concept  demonstrator  was  in  the  main  restricted  to  the 
afterburner.  The  concept  demonstrator  allows  in-depth  troubleshoor'ng  to  be 
performed.  The  degree  of  integrity  and  veracity  with  which  IFDIS  p-  rformed  its 
diagnostic  task  was  however  an  unknown  quantity. 

It  is  the  goal  of  this  document  to  examine  the  possible  alternatives  available 
to  ensure  that  IFDIS  performs  with  a  high  degree  of  integrity  and  veracity. 


3.  JUSTIFICATION  FOR  INVESTIGATIVE  EFFORT  INTO  VERIFICATION 
AND  VALIDATION  OF  IFDIS. 

To  facilitate  the  development  of  procedures  for  raising  the  diagnostic 
performance  of  IFDIS,  methods  which  are  integral  to  the  development  process  will 
be  examined.  These  methods  are  required  to  be  such  that  they  enhance  the  normal 
system  development  and  produce  a  high  quality  final  product . 
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The  environment  of  aircraft  fault  diagnosis  has  several  special  considerations 
which  demand  that  an  effort  in  verification  and  validation  of  any  diagnostic  system 
be  undertaken.  These  considerations  are  the  high  cost  (  both  human  and  monetary) 
which  is  involved  with  incorrect  diagnosis,  the  complexity  of  the  engine,  and  the 
need  for  the  expert  system  to  be  an  expert  advisor  to  maintenance  personnel.  To 
perform  this  latter  role  successfully  the  fundamental  requirement  is  that  the  system 
provides  advice  which  justifies  the  title  of  ’Expert  Advisor’.  If  the  users  do  not 
perceive  this  quality  of  advice  to  be  present,  then  their  confidence  in  the 
consultation  sessions  may  be  expected  to  be  low. 

The  task  is  further  complicated  by  the  performance  of  current  diagnostic 
techniques.  The  figure  for  successful  diagnosis  of  an  engine  fault  with  current 
procedures  is  commonly  placed  at  approximately  50%.The  introduction  of  a  system 
like  IFDIS  provides  a  chanc  „  to  improve  this  situation  if  action  is  taken  to  raise  the 
level  of  ’deep  knowledge’  behind  the  IFDIS  diagnostic  decisions.  This  possibility  of 
improving  the  low  success  rate  is  a  major  incentive  to  expend  the  effort  involved  in 
verifying  and  validating  the  expert  system  to  a  level  above  current  diagnostic 
procedures. 


4.  OVERALL  STRATEGY. 

If  the  requirement  for  ensuring  that  an  expert  system  performs  to  a  high  level 
of  quality  is  accepted,  then  the  choice  of  the  overall  strategy  which  should  be 
adopted  is  the  first  issue  to  be  addressed. 

Two  overall  strategies  present  themselves  as  the  possible  alternatives.  The 
first  method  would  be  to  develop  the  system  to  the  point  where  it  could  perform  the 
troubleshooting  task,  and  to  then  focus  energies  upon  correcting  faults  in  the 
developed  system.  The  second  strategy  would  be  to  apportion  a  degree  of  the 
resources  available  at  every  phase  to  ensure  that  the  end  result  of  each  phase  was  of 
the  highest  attainable  quality,  and  hence  that  the  end  product  was  as  complete  as 
possible  at  that  point  in  time. 

The  fundamental  difference  between  these  two  approaches  is  in  effectiveness 
of  effort. 

The  first  method  of  developing  the  system  and  then  correcting  it,  has  to 
contend  with  the  inertia  of  an  existing  system.  This  requires  effort  and  resources  to 
ensure  that  corrections  and  changes  are  propagated  throughout  the  entire  system. 
Furthermore  implementing  these  changes  may  prove  to  be  impractical  if  the 
detected  fault  is  fundamental  to  a  large  part  of  the  troubleshooting,  and  hence  the 
effort  involved  is  comparable  to  a  major  rewrite  of  the  knowledge  base. 

The  second  method  of  continuous  assessment  during  the  development  of  the 
system  tends  to  use  the  minimum  effort  for  the  maximum  effect.  This  occurs  when 
mistakes  are  corrected  as  they  occur  and  hence  before  they  have  a  chance  to 
propagate  throughout  the  system. 
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So  in  terms  of  efficient  use  of  resources  the  second  method  may  be  seen  to 
be  the  ideal  towards  which  the  development  methods  of  the  system  should  aspire. 

Therefore  all  of  the  phases  which  are  involved  in  developing  an  expert  system  are 
examined  below,  and  procedures  are  defined  for  each  of  the  phases  which  are  aimed 
at  maximising  the  quality  of  knowledge  in  the  final  product,  as  well  as  maintaining 
the  knowledge  quality  throughout  the  life  of  the  system. 

For  the  purposes  of  this  description  the  development  of  a  fault  diagnosis 
expert  system  has  been  divided  into  the  following  phases: 

Knowledge  Acquisition, 

Knowledge  Manipulation, 

Knowledge  Validation  and  Verification, 

Knowledge  Support. 


5.  KNOWLEDGE  ACQUISITION. 

Knowledge  acquisition  is  the  first  phase  of  the  expert  system  creation.  The 
quality  of  the  knowledge  which  is  acquired  at  this  stage  is  the  fundamental  limiting 
factor  for  the  performance  of  the  expert  system.  The  expert  system  is  based  upon 
this  knowledge  and  without  feedback  the  system  can  never  perform  above  the 
quality  of  this  knowledge.  The  job  of  the  knowledge  engineer  is  to  strive  to  represent 
this  knowledge  as  exactly  as  possible.  As  the  knowledge  engineer  is  not  a  domain 
expert,  it  should  not  be  the  knowledge  engineer’s  task  to  raise  the  quality  of  the 
knowledge  above  that  originally  acquired  for  the  system.  Therefore  it  can  be  seen 
that  the  efforts  of  the  knowledge  engineer  can  only  be  justified  when  the  knowledge 
acquired  from  domain  experts  is  considered  to  be  of  a  high  standard. 

5.1.  Maximising  the  Quality  of  Acquired  Knowledge. 

If  optimum  performance  is  sought  from  the  expert  system  then  the  task  of 
acquiring  the  knowledge  should  be  tailored  to  the  nature  of  the  problem,  in  this  case 
the  TF30-P3.  A  modern  gas  turbine  engine  such  as  the  TF30-P3  is  among  the 
most  complex  mechanical  systems  in  use  today.  The  parameters  involved  in 
diagnosing  a  fault  are  numerous  and  often  subtly  inter-related.  The  knowledge 
involved  in  successfully  diagnosing  faults  must  be  such  that  it  recognises  these 
interrelations  and  their  implications.  So  the  initial  problem  becomes  one  of  how  to 
acquire  such  knowledge. 

The  sources  of  knowledge  which  are  available  for  the  TF30-P3  are: 

1.  Maintenance  documentation, 

2.  Maintenance  personnel  (technical  &  engineering). 

3.  Propulsion  engineers  (ARL  &  PWA). 

In  order  to  extract  the  maximum  from  these  information  sources  it  should  be 
recognised  that  two  fundamentally  different  forms  of  knowledge  are  present.  These 
are  heuristic  or  experiential  knowledge,  and  engineering  knowledge.  It  has  been 
previously  recognised  [1]  that  the  optimum  path  for  many  expert  systems  lies  in 
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developing  their  knowledge  bases  using  the  individual  strengths  of  both  types  of 
knowledge.  It  is  proposed  here  that  it  would  be  possible  to  utilise  the  information 
sources  given  above,  to  develop  a  system  based  upon  both  types  of  knowledge.  This 
is  seen  as  being  advantageous  given  the  complexity  of  the  problem. 

In  order  to  optimise  the  acquired  knowledge,  the  knowledge  types  should  be 
implemented  according  to  their  strengths.  Examination  of  the  exclusive  use  of  either 
type  reveals  the  strengths  and  weaknesses  of  each  knowledge  source. 

Engineering  knowledge  is  that  knowledge  which  is  solely  derived  from  an 
understanding  of  the  system’s  design.  This  knowledge  forms  a  description  of  the 
system  and  its  possible  behaviours. Such  knowledge  may  be  obtained  from 
descriptive  documentation  including  the  maintenance  documentation,  and  from 
personnelsuch  as  propulsion  engineers  who  are  familiar  with  design  considerations. 
From  these  knowledge  sources  it  is  possible  to  systematically  examine  the  entire 
engine,  at  a  component  level  that  is  appropriate  to  the  troubleshooting  task.  The 
aim  of  this  examination  is  to  enumerate  component  behaviour,  relationships  and 
effects  with  and  upon  other  components,  and  any  relevant  observables. 

The  result  of  this  process  is  that  it  effectively  defines  the  scope,  coverage,  and 
completeness  which  may  be  attributed  to  the  expert  system.  It  also  provides  the 
system  with  a  deeper  level  of  knowledge  than  is  possible  with  purely  experiential 
reasoning  .This  high  degree  of  completeness  is  the  major  strength  of  engineering 
analysis,  however  the  implications  of  this  completeness  show  the  major  weakness  of 
engineering  analysis.  For  although  it  provides  the  foreseeable  range  of  fault 
possibilities  for  a  given  set  of  symptoms,  it  does  not  provide  a  basis  for 
discriminating  between  the  possibilities.  In  effect,  engineering  analysis  provides  the 
possibilities  which  should  be  considered,  but  it  does  not  reveal  the  optimum 
troubleshooting  paths  to  arrive  at  and  eliminate  possibilities. 

Experiential  knowledge,  by  comparison,  is  gained  from  experience  in 
maintaining  the  engine.  It  is  based  upon,  for  the  TF30-P3,  well  established 
troubleshooting  techniques,  the  historical  record  of  symptom  to  fault, relationships, 
and  a  hands-on  knowledge  of  the  engine’s  operation.  The  sources  of  experiential 
knowledge  are  the  maintenance  personnel  and  the  troubleshooting  documentation. 
This  knowledge  type  is  aimed  at  finding  the  most  probable  causes  of  any  problem 
and  addressing  the  order  in  which  they  should  be  investigated  to  find  the  actual 
cause  in  the  minimum  time.  The  strength  of  this  knowledge  type  is  this  inherent 
focusing  upon  the  most  probable  cause  of  the  unserviceability.  The  accompanying 
drawback  however  is  that  this  focused  outlook  does  not  provide  an  indication  as  to 
the  coverage  which  has  been  achieved  for  the  problem.  Furthermore  experiential 
knowledge  has  difficulty  dealing  with  a  fault  that  has  not  been  experienced  before. 
This  means  that  extremely  rare  or  first  occurrences  of  a  fault  will  not  be  correctly 
diagnosed  or  even  considered. 

From  the  preceding  description  it  may  be  seen  that  exclusive  use  of  either 
type  of  knowledge  leads  to  a  knowledge  base  which  is  deficient  in  some  important 
performance  aspect.  It  may  also  be  seen  that  the  two  types  of  knowledge  are 
complementary  in  that  the  deficiencies  of  one  are  covered  by  the  characteristics  of 
the  other. 
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This  leads  to  the  conclusion  that  a  system  which  acquires  its  scope,  structure, 
and  completeness  from  engineering  analysis,  and  acquires  its  controlling  and 
troubleshooting  guidance  from  experiential  sources,  will  be  an  expert  system  which 
has  the  capability  of  performing  with  a  high  degree  of  integrity  and  veracity. 

5.2.  Acquiring  Engineering  and  Experiential  Knowledge. 

The  task  of  acquiring  the  knowledge  so  that  it  conforms  to  the  above  ideal 
may  be  achieveable  by  several  knowledge  acquisition  techniques.The  basic 
requirement  is  that  the  knowledge  engineer  receives  input  from  both  experiential 
and  engineering  knowledge  sources. 

It  is  envisaged  that  this  may  be  achieved  by  the  knowledge  engineer 
acquiring  knowledge  from  a  team  of  experts,  being  personnel  who  are  considered  as 
the  most  capable  of  examining  and  debating  to  a  satisfactory  conclusion  the 
troubleshooting  problems  at  hand. 

It  is  envisaged  that  the  team  would  be  led  by  a  senior  engineer  who  is 
responsible  for  conflict  resolution  and  communication  of  knowledge  to  the 
knowledge  engineer.  The  team  would  be  comprised  of  maintenance  technicians  and 
engineers  who  are  familiar  with  the  engine.The  maintenance  technicians  would 
provide  the  main  heuristic  input  to  the  knowledge,  while  the  role  of  the  engineers 
would  be  to  provide  engineering  analysis  of  the  fault  situation.  In  this  way  the 
engineers  on  the  panel  set  out  in  a  particular  problem  field  to  enumerate  the 
possible  faults  and  system  behaviours.  An  example  of  this  is  given  in  Appendix  1 
where  the  problem  of  full  afterburner  power  not  being  attainable  is  examined 
purely  from  a  description  of  the  engine  design. 

The  maintenance  technicians  may  then  apply  their  knowledge  to  the  matter 
of  troubleshooting  the  faults  listed  as  possible.  Any  conflict  in  opinion  between  the 
two  knowledge  sources  would  be  resolved  by  the  requirement  to  justify  any 
conflicting  beliefs  to  the  senior  engineer .  This  arrangement  allows  the  strengths  of 
both  types  of  knowledge  to  be  exploited.  The  scope  of  any  investigation  would  be 
determined  by  the  propulsion  engineers  and  the  troubleshooting  procedure  by  the 
maintenance  technicians. 


6.  KNOWLEDGE  MANIPULATION. 

Once  the  knowledge  has  been  acquired  the  next  phase  of  development  which 
has  a  bearing  upon  the  expert  system’s  performance  is  the  knowledge  manipulation. 
Knowledge  manipulation  may  be  thought  of  as  the  processes  involved  in  turning  the 
acquired  knowledge  into  verifiable  rules  and  an  associated  inference  engine.  It  is  the 
knowledge  engineer’s  task  to  interpret  the  acquired  knowledge  into  a  rule  set.  It  is 
not  the  purpose  of  this  document  to  delve  into  the  knowledge  engineer’s  task,  and  as 
such  the  interpretation  process  will  not  be  detailed.  However,  knowledge 
manipulation  may  also  involve  the  development  of  a  method  with  which  to  check  the 
developed  rule  set.  The  options  which  are  available  for  providing  the  knowledge 
supervisor  with  a  facility  for  checking  the  rule  set  are  detailed  below. 
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6.1.  Application  of  Acquired  Knowledge  to  Check  Developed  Rule  Sets. 

The  knowledge  which  has  been  acquired  in  the  first  phase  of  operations  may 
be  applied  by  the  knowledge  supervisor  and  associated  personnel  to  ensure  the 
performance  of  the  expert  system.  Two  possible  methods  of  applying  the  acquired 
knowledge  to  verify  rules  are  outlined  below.  These  involve  causal  justification  of 
rules  and  the  development  of  a  qualitative  fault  model. 

6.2.  Causal  Justification  of  Rules. 

The  knowledge  engineer  attempts  to  interpret  the  acquired  knowledge  into 
rules.  This  implies  that  the  knowledge  engineer  forms  the  rule  from  his  or  her 
interpretation  of  the  reasoning  which  was  extracted  from  the  experts.  In  this  way  the 
knowledge  engineer  arrives  at  a  set  of  conditions,  and  a  set  of  conclusions  and 
actions  which  pertain  to  each  individual  hypothesis  or  rule.  The  main  question  at 
this  stage  is:  how  can  it  be  ensured  that  the  knowledge  engineer  has  successfully 
translated  the  expert’s  reasoning  and  conclusion  into  a  rule? 

Causal  justification  of  rules  aims  at  providing  a  method  to  achieve  this 
requirement.  A  rule  may  be  said  to  be  causally  justified  when  the  linkages  between 
the  conditions  and  the  actions  of  the  rule  are  enumerated  in  a  causal  fashion.  This 
enumeration  is  required  to  be  such  that  an  independent  engineer,  with  experience  in 
the  field  of  jet  propulsion  and  access  to  TF30-P3  documentation,  would  be  able  to 
follow  and  judge  the  validity  of  the  causal  linkages.  An  example  of  this  method  is 
given  below. 

Example 

In  troubleshooting  the  unserviceability  of  "Full  Afterburner  power  not 
available."  the  following  rule  may  be  employed.  This  rule  is  brought  into 
consideration  when  the  symptom  set  provided  by  the  user  agrees  with  the  rule’s 
conditions.  This  is  not  the  sole  conclusion  which  may  be  derived  from  these 
symptoms  and  as  such  it  should  be  viewed  as  an  isolated  element  of  the  complete  set 
of  conclusions  and  actions  which  would  result  from  the  symptoms  provided. 

IF  full  afterburner  power  not  available, 

AND  fuel  flow  state  at  maximum  is  steady, 

AND  fuel  flow  maximum  (on  ground  )  <  32000pph, 

AND  nozzle  position  at  maximum  <  10, 

THEN  Afterburner  Fuel  Pump  is  possible  fault. 

Causal  Justification. 

A  degraded  afterburner  pump  will  not  be  capable  of  producing  the  fuel  flow 
rate  and  head  required  by  maximum  afterburner  selection.  The  result  of  a  fuel  pump 
degradation,  if  the  pump  is  still  operating,  will  be  either  a  reduced  flow  at  the 
required  head  or  a  reduction  in  the  head  obtainable,  both  of  which  would  normally 
result  in  reasonably  steady  conditions.  Therefore  if  the  afterburner  pump  is  the  fault 
then  the  fuel  flow  may  well  be  steady  and  below  32000pph.  If  the  exhaust  nozzle 
control  is  operating  correctly  it  will  not  allow  the  nozzle  area  to  reach  10.  This  will 


be  required  as  the  reduced  fuel  flow  would  result  in  a  low  Pt7  if  the  nozzle  attained 
10.  Hence  the  exhaust  nozzle  control  will  lower  the  nozzle  area  to  maintain  the 
desired  turbine  pressure  ratio.  Therefore  the  symptoms  which  may  be  noted  with  a 
faulty  afterburner  pump  are: 

(1) .  reduced  but  steady  fuel  flow,  and 

(2) .  reduced  nozzle  size. 

These  justifications  not  only  allow  the  verification  and  validation  of  the 
expert  system  to  be  carried  out  but  they  also  may  be  manipulated  to  facilitate  the 
knowledge  support  as  will  be  described  in  the  knowledge  support  section. 

6.3.  Qualitative  Fault  Model. 

Acquiring  experiential  and  engineering  knowledge  of  the  TF30-P3 
provides  an  opportunity  to  develop  a  qualitative  fault  model  for  the  engine.  This 
task  is  compatible  with  a  desire  to  produce  an  expert  system  which  performs  with  a 
high  degree  of  integrity  and  veracity.  As  developing  the  qualitative  model  captures 
the  acquired  knowledge  in  a  form  which  can  be  used  to  verify  and  validate  the 
expert  system. 

A  qualitative  fault  model  is  a  computer  simulation  of  the  engine  which 
utilises  the  qualitative  relationships  between  engine  and  aircraft  components  to 
model  engine  behaviour.  The  type  of  model  which  may  be  constructed  is  dictated  by 
the  knowledge  which  is  available  and  the  relative  value  of  the  knowledge  in 
constructing  a  fault  model.  These  factors  of  applicability  and  availability  of 
information  resulted  in  the  choice  of  a  qualitative  model  as  opposed  to  a 
quantitative  model.  The  qualitative  information  available  on  the  TF30-P3  is  of 
sufficient  detail  to  construct  a  qualitative  model  which  would  be  useful  for  verifying 
a  diagnosis  system.  In  contrast  the  quantitative  data  are  in  general  not  as  readily 
available  and  even  if  available  they  do  not  readily  lend  themselves  to  the  task  of 
fauit  modelling. 

Therefore  if  the  knowledge  which  has  been  acquired  for  the  expert  system  is 
to  be  utilised  in  the  construction  of  the  qualitative  model  then  the  nature  of  the 
model  is  predetermined  to  a  large  extent.  For  the  knowledge  gained  in  the 
development  of  the  expert  system  deals  almost  exclusively  with  line  replaceable 
units  and  their  observable  behaviour.  This  dictates  the  fundamental  model  elements 
(typically  aircraft  or  engine  components)  which  the  modelling  process  utilises  and 
the  interactions  between  these  elements  which  the  model  will  consider. 
Furthermore  the  purpose  of  using  this  model  to  check  the  performance  of  the  expert 
system,  provides  most  of  the  additional  guide-lines  required  for  the  model’s 
structure.  This  requirement  specifies  the  behaviours  which  are  to  be  considered  in 
the  model.  The  behaviours  are  those  associated  with  each  failure  mode  for  any 
component  of  the  model  which  has  been  considered  in  the  expert  system. 

Hence  the  form  which  the  model  will  take  is  reasonably  defined  by  the 
considerations  given  above.  For  further  description  of  the  qualitative  model  concept 
and  an  example  of  a  limited  qualitative  model,  which  deals  with  the  operation  of  the 
TF30-P3  afterburner,  refer  to  Appendix  2. 
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The  method  of  using  a  qualitative  fault  model  to  check  the  expert  system  is 
further  detailed  in  the  verification  and  validation,  and  expert  system  support 
sections.  Briefly,  the  QFM  enhances  these  later  stages  of  the  development  process 
by  providing  a  systematic  way  of  checking  the  entire  expert  system’s  performance, 
hence  providing  a  check  for  the  integration  of  all  related  causal  justifications  into  a 
cohesive  system. 


7.  VALIDATION  *ND  VERIFICATION. 

The  process  of  validation  and  verification  should  be  the  natural  culmination 
of  the  work  done  in  the  knowledge  manipulation  phase.  The  way  in  which  this  can 
be  achieved  is  set  out  below. 

7.1.  Causal  Justification. 

Validation  and  verification  using  causal  justification  is  an  iterative  process. 
The  knowledge  engineer  provides  the  knowledge  supervisor  with  subsets  of  the  rules 
and  their  justifications  as  they  are  developed.  The  knowledge  supervisor  then 
instructs  a  propulsion  engineer  to  review  all  justifications.  This  review  compares  the 
justifications  to  the  knowledge  as  acquired  and  determines  whether  the  rule  is  an 
accurate  representation  of  the  causal  justification,  and  if  the  causal  justification  is  in 
itself  valid. 

Feedback  regarding  any  proposed  changes  which  are  required  to  correct 
detected  errors  is  then  provi^M  to  the  knowledge  engineer  .  The  knowledge 
engineer  may  then  address  the  identified  errors.  The  final  justification  then  occurs 
when  the  rules  and  justifications  submitted  by  the  knowledge  engineer  are  deemed 
satisfactory  by  the  knowledge  supervisor. 

12.  Qualitative  Fault  Model. 

If  the  knowledge  acquired  in  the  first  phase  of  the  system  development  was 
utilised  to  produce  a  qualitative  fault  model  (QFM)  then  the  verification  of  the 
system  may  proceed  as  follows.  The  fault  model  may  be  activated  so  that  the 
symptom  sets  associated  with  each  fruit  are  generated.  These  symptom  sets  may 
now  be  used  to  answer  the  diagnostic  queries  of  the  expert  system.  The  system  may 
be  considered  to  be  performing  satisfactorily  when 

1.  the  fault  associated  with  the  symptom  set  is  identified  as  ’indicated’. 

2.  other  faults  which  the  system  determines  to  be  ’indicated’  or  ’  possible’ 
are  not  associated  with  contradictory  symptom  sets  . 

3.  those  faults  with  symptom  sets  which  are  not  contradictory  to  the  input 
symptom  set  are  not  rated  as  ’not  indicated’  by  the  system. 

When  the  system  can  satisfy  these  three  conditions  for  the  entire  fault  set 
then  it  may  be  considered  to  be  verified. 


j 
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8.  KNOWLEDGE  SUPPORT. 

Knowledge  support  is  the  mechanism  by  which  the  expert  system’s  support 
authority  responds  to  feedback  from  the  users,  and  implements  new  knowledge  as  it 
becomes  available.  The  feedback  from  the  users  identifies  any  errors  which  may 
have  escaped  detection  during  the  development  process,  as  well  as  allowing  the 
users  have  an  :nput  into  improving  the  system  when  they  consider  that  an 
improvement  in  tne  diagnosis  could  be  achieved.  The  implementation  of  new 
knowledge  as  it  becomes  available  allows  the  system  to  respond  to  updates  in  the 
engine  and  to  changing  operating  environment  aspects,  such  as  the  ageing  of  the 
fleet,  and  any  changes  in  usage  of  the  fleet. 

The  approach  to  knowledge  support  is  dependent  upon  the  development 
method  which  was  utilised.  If  causal  justification  was  employed  to  verify  the  original 
system  then  this  method  can  be  extended  to  perform  the  knowledge  support  role. 

In  this  case  the  response  to  feedback  involves  the  initiator(s)  of  the  feedback 
setting  out  the  perceived  error  in  the  system.The  support  authority  may  then 
respond  to  the  problem  by  reviewing  the  justifications  used  in  the  suspect  area  to 
determine  any  possible  fault  in  belief  or  execution  by  the  system.  If  such  a  fault  is 
found  then  the  proposed  correction  must  be  causally  justified  and  the  change 
propagated  throughout  the  system. 

New  knowledge  may  be  dealt  with  by  determining  the  alterations  and 
additions  which  this  new  information  projects  onto  the  knowledge  which  was  used  to 
construct  the  system.  To  achieve  this  the  justifications  used  in  the  development  and 
support  of  the  system  are  reviewed  to  determine  what  changes  are  required.  The 
changes  may  then  be  implemented  to  utilise  this  new  knowledge.  In  this  way  the 
causa!  justifications  associated  with  the  expert  system  rules  may  be  used  to  maintain 
the  system. 

If  in  addition  a  QFM  was  constructed  during  the  system  development  then  all 
possibilities  for  knowledge  support  mentioned  above  are  possible.  Additionally  the 
QFM  may  be  used  to  great  advantage  in  the  knowledge  support  role  if  any  changes 
which  are  deemed  to  be  worth  implementing  on  the  expert  system  are  reproduced 
on  the  QFM.  This  having  been  done  the  QFM  may  then  be  run  for  the  full  fault  set 
to  observe  any  alterations  in  symptom  sets  associated  with  any  faults.  In  this  way  the 
full  implications  of  any  change  to  the  knowledge  behind  the  expert  system  may  be 
revealed.  This  provides  the  opportunity  to  note  implications  of  the  feedback  or  new 
knowledge  which  otherwise  may  not  t.  ve  been  recognised. 

In  this  way  a  QFM  may  be  used  to  significantly  enhance  the  knowledge 
support  performance  of  the  justification  process  given  above. 


9.  CONCLUSIONS 

The  ‘complete  approach’  is  required  to  produce  a  diagnostic  expert  system 
which  performs  with  the  highest  degree  of  integrity  and  veracity. 
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This  'complete  approach'  involves  all  phases  of  the  system  development  as 
follows: 

Knowledge  acquisition  acquires  engineering  knowledge  to  determine  the 
scope  of  the  knowledge  required,  and  acquires  experiential  knowledge  to  focus  the 
troubleshooting  most  appropriately. 

Knowledge  manipulation  should  transform  the  acquired  knowledge  into  a 
representation  that  may  readily  be  proven  to  be  an  accurate  or  inaccurate 
interpretation  of  the  expert’s  knowledge(  which  represents  the  best  knowledge 
available  at  the  time  of  acquisition).  This  is  achieved  by  supplying  causal  justification 
for  all  of  the  rules  in  the  expert  system  to  the  knowledge  supervisor  who  will  only 
pass  the  rules  when  satisfied  that  they  accurately  represent  the  knowledge  as 
acquired.  If  the  resources  are  available  the  acquired  knowledge  may  also  be  utilised 
to  develop  a  qualitative  fault  model  of  the  engine.  This  development  is  seen  as  being 
justified  by  the  enhancement  in  the  quality  of  the  validation  and  verification,  and 
the  support  phases  of  the  expert  system  development. 

Knowledge  validation  and  verification  is  seen  as  a  process  which  should  have 
its  basis  in  the  knowledge  manipulation  phase.  Initially  during  the  manipulation 
phase  and  finally  in  the  validation  and  verification  phase  the  knowledge  engineer 
should  supply  the  knowledge  supervisor  with  the  proposed  justifications  for  the  rules 
in  the  expert  system.This  is  an  iterative  process  which  is  carried  out  until  the 
knowledge  supervisor  is  satisfied  that  the  rules  and  their  justifications  accurately 
represent  the  knowledge  as  acquired.  Further,  if  a  qualitative  fault  model  has  been 
developed  it  may  be  used  to  examine  the  system’s  performance  over  the  entire 
problem  domain.  In  that  way  it  is  possible  to  ensure  that  the  system  as  a  whole 
performs  to  the  potential  of  the  justified  component  system  elements. 

Knowledge  support  is  achieved  by  taking  the  feedback  and  new  knowledge 
which  becomes  available  and  passing  it  through  an  extension  of  the  same  process 
which  the  originally  acquired  knowledge  was  subject  to.  In  this  way  the  system’s 
performance  can  be  increased  above  the  level  achievable  with  the  original  expert 
knowledge.  Hence  the  system  has  the  capability'  of  providing  expert  advice  which 
starts  off  as  being  the  best  available  at  the  time  of  release,  and  improves  with  time. 

This  complete  approach  affects  all  aspects  of  the  development  and  support  of 
the  expert  system.  It  is  the  most  effective  way  of  producing  an  expert  advisor  which 
performs,  and  will  continue  to  perform  with  the  highest  degree  of  integrity  and 
veracity. 

As  such  it  is  recommended  that  all  phases  in  the  development  of  IFDIS  or  a 
similar  system  should  be  carried  out  in  such  a  way  that  the  ability  to  verify  and 
validate  the  system  being  generated  is  a  primary  goal  of  all  personnel  involved.  Then 
systems  may  be  produced  which  can  successfully  make  the  transition  from 
prototypes  to  operational  expert  advisory  systems. 
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Appendix  1,  Troubleshooting  "Full  Afterburner  Power  Not  Available"  bv  Engineering 
Analysis. 

1.  Unserviceability  definition. 

"Full  afterburner  power  not  available "  describes  several  possible  engine  conditions,  if  maximum 
afterburner  has  been  selected  on  the  throttle  and  either  the  nozzle  indication  is  below  10,  or  fuel 
flow  is  below  expected  (36000pph  on  the  ground),  or  EPR  is  below  day  temperature  limits  then 
any  occurrence  or  combination  of  these  symptoms  leads  to  the  unserviceabilty  "Full  afterburner 
power  not  available 

2. First  level  analysis  of  Primary  symptoms. 

In  order  to  ascertain  the  relevant  starting  points  for  the  physical  investigations,  the  primary 
symptoms  listed  above  were  examined.  These  symptoms  provide  pointers  to  the  influences  of 
the  fault.  The  naming  of  these  influence  occurrences,  in  turn  generates  the  directions  which  the 
next  level  of  investigation  should  follow. 

This  first  level  analysis  leads  to  the  following  influences  being  identified. 

Primary  symptom;Aj<10  &  Wf=36000pph. 

POSSIBLE  CAUSES 
1  Nozzle  positioning  incorrect, 

2.  Nozzle  position  indication  incorrect, 

3.  Fuel  utilisation  is  substandard. 

Primary  symptom;Aj<10  &  Wf<36000pph. 

POSSIBLE  CAUSES 

These  include  those  listed  above  with  the  addition  of 

4.  Fuel  flow  supply  below  the  required  level. 

Primary  symptom;Aj=10  &  Wf<36000pph. 

POSSIBLE  CAUSES 

The  causes  of  these  symptoms  are  covered  by  those  given  above. 
Primary  symptom;EPR  not  attained. 

It  should  be  noted  that  the  point  considered  most  critical 

for  EPR  is  at  Military  power.  Hence  it  is  unlikely  that  the  engine  would  fail  EPR  requirements  at 
Maximum  afterburner  power  after  passing  the  requirements  at  Military  power.  However  for  the 
sake  of  completness  the  EPR  case  will  be  examined. 

POSSIBLE  CAUSES 

5.  Engine  efficiency  below  required  level. 

All  of  the  events  listed  above  under  POSSIBLE  CAUSES  may  be  considered  as  the  fault 
influences  which  were  observed  when  the  unserviceability  was  reported.  The  analysis  may  now 
procede  by  tracing  the  causal  chains  which  could  produce  these  observed  influences. 
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3. Causal  chain  fault  tracing. 

The  aim  of  this  investigative  step  is  to  identify  the  set  of  faults  which  could  produce  each 
observed  fault  influence.  This  is  achieved  by  determining  the  departures  from  correct  operation 
which  could  cause  the  fault's  observable  influences.  Examination  of  the  roles  of  components 
which  are  involved  in  these  suspect  operations  reveals  the  components  which  have  the  potential 
to  produce  the  observed  symptoms. 

The  investigative  process  involved  in  identifing  the  potential  faulty  component  set  is  given  in 
figure  1 . 


Figure  1 . 


Departures  from  correct  operation. 

By  dealing  with  each  observable  influence  in  turn  the  responsible  departures  from  correct 
operation  may  now  be  determined. 


1  Nozzle  positioning  incorrect 

Examination  of  the  engine  reveals  the  departures  from  correct  operation  which  may  be 
responsible  for  incorrect  nozzle  positioning.  These  have  been  listed  out  below. 

EITHER: 

1 .1  Nozzle  positioning  system  received  incorrect  instruction. 

OR: 

1 .2.  Nozzle  positioning  system  incapable  of  correctly  executing  instruction. 

OR: 

1 .3.  Nozzle  positioning  system  missinterprets  state  of  Aj  and/or  other  input  parameters. 


The  departures  from  correct  operation  listed  above.  (1.1, 1 .2, 1 .3),  may  now  be  individually 
examined  to  determine  the  components  involved  in  the  operations.  This  will  reveal  the  potentially 
faulty  component  set.  Furthermore  the  effects  of  the  failures  listed  may  be  traced  to  confirm  the 
primary  symptoms  which  should  be  expected  for  the  listed  failure. 
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1.1  Nozzle  positioned  incorrectly  having  received 
incorrect  instructions. 

The  nozzle  receives  positioning  instructions  via  the  PLA 
input. 

PLA  request  originates  at  the  throttle  and  is  transmitted  via  the  throttle  linkages.  Hence  it  may  be 
seen  that  the  critical  components  are  the  throttle  and  throttle  linkages. 

The  implications  of  missrigging  may  now  be  examined  to  confirm  the  possibility  of  these 
components  being  at  fault. 

IF  throttle  and  throttle  linkages  are  missrigged  low  THEN 
120  degrees  PLA  not  reqested 
AND 
Aj<1 0, 

AND 

Wf  scheduled<36000pph 

HENCE  1 .1  =>THROTTLE  &  THROTTLE  LINKAGES  would  belong 
to  the  Aj<10  &  Wf<36000pph  problem  class. 

1 .2.Nozzle  positioning  system  incapable  of  correctly  executing  instruction. 

The  nozzle  is  positioned  by  the  actuators  which  are  in  turn  positioned  by  the  ENC  Nozzle 
positioning  svstem. 

It  may  be  seen  therefore  that  if  the  nozzle  is  incapable  of  Aj=10  due  to  stuck  actuators  or  ENC 
that  Wf  <  36000pph  by  feedback  &  Pb/Pt7  system  which  is  operating  correctly. 

HENCE  1.2  =>ACTUATORS  &  POSITIONERS  is  in  the  Aj<10 
&  Wf<36000pph  problem  class. 

1.3  Nozzle  positioned  incorrectly  due  to  incorrect 
parameter  state  input. 

This  must  be  further  subdivided  to  account  for  the  different 
inputs. 

(a)Pt7  as  the  input  parameter. 

Pt7  is  sensed  by  a  Pt7 probe  &  transmited  to  Pb/Pt7  system. 

The  Pb/Pt7  system  then  commands  nozzle  positioning 
IF  Pt7  received  is  lower  than  actual  THEN 

Pb/Pt7  system  will  lower  Aj  to  compensate  for  the  perceived  Pt7  error.  This  will  raise  Pt7  above 
desirable  levels,  and  may  produce  an  unsustainable  pressure  ratio  across  the  engine  fan.  This 
may  result  in  a  stall.  (Note  this  is  an  example  of  how  the  analysis  can  reveal  other  implications  of 
a  fault.  In  this  case  depending  upon  operating  conditions  this  fault  may  result  in  a  completely 
different  unserviceability  being  reported  i.e.  " Engine  Stalls  at  some  Intermediate  Zone  of 
Afterburnino".) 

HENCE  1 ,3.(a)=>Pt7  PROBE  &  LINE  will  result  in  Aj<1 0  & 

W<=36000pph. 


A. 1.3 


(b)Pb  as  the  input  parameter. 

The  Pb  signal  to  ENC  Pb/Pt7  system  commands  nozzle  positioning 
IF  Pb  received  is  above  actual  THEN 
Pb/Pt7  system  will  lower  Aj 
AND 

stall  may  result 

HENCE  1.3.(b)BLOCKED  ENC  Pb  LINE  will  result  in  Aj<10  & 
Wf=36000pph. 


(c)Aj  as  the  input  parameter. 

The  feedback  rigging  transmits  Aj  to  ENC  which  compares  signal  to  requested  Aj  and  Wf  is 
rescheduled. 

IF  Feedback  rigging  indicates  Aj  higher  than  actual  THEN 
Aj  (actual)  <10 
AND 

Aj  (indicated)=10 
AND 

Wf<36000pph  (due  to  down  trimming  by  Pb/Pt7  system) 

HENCE  1 ,3.(c)FEEDBACK  RIGGING  HIGH  will  result  in  the  third 
class  of  problem  Aj(indicated)=10,Wf<36000pph. 

IF  Feedback  ngging  indicates  Aj  lower  than  actual  THEN 
Aj  (indicated)«10 
AND 

Aj  (actual)<l  0  (due  to  low  Wf  schedule  and  Pb/Pt7  system) 

AND 

Wf<36000pph 

HENCE  1 ,3.(c)FEEDBACK  RIGGING  LOW  will  result  in  a 
problem  of  the  Aj<10,Wf<36000pph  class. 


In  summary  of  the  findings  so  far,  the  potential  faulty  component  set  which  is  responsible  for  the 
observable  fault  influence  of  incorrect  nozzle  positioning  is  as  follows. 

*  Throttle  setting  stops, 

*  Throttle  linkage  rigging, 

*  Nozzle  actuators, 

*  ENC  nozzle  positioning  system, 

*  Pt7  probe  and  sense  line, 

*  ENC  Pb  line, 

*  Nozzle  feedback  rigging. 

This  same  process  may  now  be  carried  out  for  the  remaining  observable  fault  influences.  The 
potential  faulty  component  sets  which  were  generated  in  this  fashion  are  listed  below. 
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Observable  fault 
influence 

Potential  faulty 
component 

Associated 
primary  symptom 

1  Nozzle  positioned 
incorrectly: 

'Throttle  setting 
stops. 

'Throttle  linkage 
rigging. 

'Nozzle  actuators. 

*ENC  nozzle 
positioning  system. 

*Pt7  probe  and 
sense  line. 

'ENC  Pb  line. 

'Nozzle  feedback 
rigging. 

'Aj<10,Wf<36000pph 

'Ajd 0,Wf<36000pph 
*Aj<1 0,  Wf<36000pph 

*Aj<1 0,Wf<36000pph 

'Aj<1 0,Wf=36000pph 
'Aj<1 0,Wf=36000pph 

*Ajd  0,Wf<36000pph 

2. Nozzle  position 
indication  incorrect: 

'Cockpit  nozzle 
indicator. 

'Ajd  0,Wf=36000pph 

3. Fuel  utilisation 
is  substandard: 

'Fuel  leak  post 

AB  pump. 

'Ajd  0,Wf=36000pph 

'Damaged  zone  rings 
or  Flame  holders. 

*Ajd  0,Wf=36000pph 

4  Fuel  flow  below 
required  level: 

'Metering  heads. 

'AB  pump. 

'AB  pump  turn  on 
switch. 

'Ajd  0,Wf<36000pph 
*Ajd  0,Wf<36000pph 

*Aj<1 0,Wf<36000pph 

4. Inferring  additional  observable  symptoms  associated  with  identified  faults. 

The  faulty  component  set  which  describes  the  possible  causes  of  full  afterburner  power  not 
available  has  now  been  established.  The  components  which  make  up  the  set  may  now  be 
examined  individually  to  identify  any  associated  secondary  symptoms.  These  secondary 
symptoms  are  required  in  order  to  differentiate  between  faulty  components  which  exhibit  identical 
primary  symptoms. 

The  processes  involved  in  inferring  and  deducing  the  secondary  symptoms  associated  with  a 
fault  are  shown  in  the  figure  below. 
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Figure  2 

This  procedure  is  demonstrated  below  for  the  fault  of  Pt7 probe  blocked  and/or  Pt7  sense  line 
leak. 

Operations  affected  by  fault 

The  Pt7  probe  senses  tailpipe  pressure.  The  sensed  pressure  is  transmitted  to  the  ENC  turbine 
pressure  ratio  controller  via  the  Pt7  sense  line. 

Hence  the  immediate  effect  of  a  failure  in  the  probe  or  sense  line  will  be  corruption  of  the  ENC 
Pb/Pt7  ratio. 

Corruption  of  the  Pb/Pt7  ratio  will  in  turn  cause  incorrect  nozzle  positioning. 

Incorrect  nozzle  positioning  will  affect  the  tailpipe  pressure  which  will  change  the  EPR  ,  such  that 
the  N1  &  N2  spool  speeds  will  alter.  The  changing  of  the  N2  spool  speed  will  be  counteracted  by 
the  main  fuel  control,  which  will  reschedule  main  engine  fuel  flow  to  maintain  desired  N2  RPM. 

Influence  of  the  fault  upon  affected  operations. 

The  faults  investigated  here  are  of  a  blockage  of  the  probe  or  a  leak  in  the  sense  line. 

If  either  of  these  conditions  exist  then  the  pressure  transmitted  to  the  ENC  will  be  lower  than  the 
actual  pressure. 

Thus  examination  of  the  operation  description  given  above  reveals  that 
1  Nozzle  will  be  positioned  lower  than  required. 

2. Tailpipe  pressure  will  be  higher  than  desired. 

3  Engine  EPR  will  be  raised. 

4  Pressure  ratio  across  the  fan  will  rise. 

From  this  set  of  conditions  the  observable  effects  of  the  fault  may  be  listed.  These  will  be  the 
Primary  and  Secondary  symptoms. 

Observable  effects  of  the  incorrect  operations. 

1  Nozzle  will  be  positioned  low.  ( ie  Aj  <  10  in  this  case  a  primary  symptom.) 

2.  EPR  may  be  high  in  comparison  to  the  other  engine. 

3.  The  engine  may  stall  due  to  increased  fan  pressure  ratio. 

4  Lightoff  detection  may  be  delayed,  and  stalling  at  AB  initiation  may  occur. 
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Hence  the  secondary  symptoms  associated  with  a  blocked  Pt7  probe  or  a  leaking  Pt7  sense  line 
are: 

1  Comparatively  high  EPR, 

2.  Engine  may  stall  at  AB  initiation,  or  at  intermediate  AB 
operation, 

3,  Nozzles  may  be  slow  to  unlock  at  AB  initiation. 

This  procedure  was  carried  out  for  all  of  the  components  identified  in  the  initial  investigation 
phase.  The  secondary  symptoms  associated  with  the  components  are  listed  below. 


Pt7  probe. 

:Engine  may  stall.Pressure  ratios  incorrect; 
:Light-off  detec  &  Noz  unlock  late;EPR  high. 

Pb  line. 

.•Pressure  ratios  incorrect;  Fuel  in  line. 

Cockpit 

indicator. 

:Measurement  &  indication  do  not  agree; 
:Engine  performance  otherwise  satisfactory. 

Flame  holders 
&  rings. 

: Visual  inspection. 

Fuel  leak. 

:Visual  inspection. 

Throttle  & 
linkages. 

;PLA<120°  When  throttle  at  MAX;Throttles 
:split  for  various  settings. 

Nozzle 

actuators. 

:Visual  inspection;Rough  noz  motion;Noz  does 
mot  totally  pop  open  below  idle. 

ABFC. 

rReduced  Wf  through  certain  zones; 

:Wf  lower  than  36000pph. 

AB  Pump. 

:Wf  lower  than  36000pph;Fuel  pressure  at 
:ABFC  zone  outlets  low. 

Pump  switch. 

:As  for  AB  pump  and;lf  Wf<4000pph  then 
•.switch  closed. 

Nozzle 

Feedback. 

:Noz  pos  indie  not  0  at  idle;Engine  may 
:tend  to  stall. 

7th  &  12th  Bleeds. 

:Check  their  operation  by  0.1  EPR  rise. 

Anti-iceing. 

:Check  their  operation  by  observation. 

:Should  be  off. 

Inlet. 

:Check  for  fully  open  position. 

ECS. 

:ll  both  engines  in  trouble  and  problem 
disappears  when  ECS  switched  away. 

ENC  trim 

:Engine  may  tend  to  stall;EPR  may  be  high.Wf 
:&  Aj  may  fluctuate  if  so  ASSK  may  alleviate. 
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This  appendix  details  work  done  on  the  development  of  a  qualitative  fault  model  for  the 
afterburner  of  the  TF30-P3. 


Modelling  Goal, 

The  model  was  developed  to  demonstrate  the  concepts  involved  in  building  a  fault  model 
for  diagnosis  of  faults  in  a  gas  turbine  engine.  The  primary  task  of  the  fault  model  was  to 
provide  an  indication  of  the  behaviour  of  the  engine  when  one  component  within  the 
engine  was  not  functioning  correctly.  Careful  examination  of  the  predicted  engine 
behaviour  then  provides  a  set  of  observable  symptoms  which  can  be  associated  with  the 
embedded  fault. 


Information  Required  for  Modeling, 

The  structure  and  content  of  the  model  was  determined  by  the  knowledge  and 
information  which  were  available  for  its  construction.  The  information  required  was  a 
description  of  the  behavior  of  all  relevant  components  and  of  the  interactions  between  the 
components.  This  information  was  required  to  be  of  sufficient  detail  so  that  the  output  of 
any  system  of  components  could  be  determined  from  the  input  to  the  system  and  the 
operational  state  of  the  components  within  the  system. 

The  documented  information  available  for  the  construction  of  this  model  consisted  of  the 
Field  Maintenance  Instructions  for  the  TF30  (reference^]),  and  the  training  notes  for  the 
RAAF  Fill  Engine  and  Fuel  Control  Unit  courses  (references[2],[3]).  As  these  were  the 
main  sources  of  information  they  dictated  that  the  model  be  qualitative  as  opposed  to 
quantitative.  Little  if  any  quantitative  data  were  given  regarding  the  performance  of  the 
components,  rather  they  supplied  descriptions  of  the  behavior  and  nature  of  the 
components. 

Therefore  a  qualitative  fault  model  was  constructed  which  could  indicate  qualitative 
changes  in  engine  parameters  which  were  considered  important. 

Structure  of  Model, 

The  structure  of  the  model  was  to  a  large  extent  determined  by  these  knowledge 
sources,  and  their  description  of  component  behaviour. 

The  type  of  knowledge  obtained  allows  the  afterburner  to  be  broken  down  into  a 
collection  of  main-systems  and  then  further  into  sub-systems.  This  process  is  continued 
until  a  level  is  reached  where  the  input-output  relationship  for  the  sub-system  is  well 
defined  for  all  input  conditions  to  the  sub-system. 

The  main-systems  considered  in  the  model  were  the  Afterburner,  Exhaust  Nozzle  Control 
(ENC),  and  the  Afterburner  Fuel  Control  (ABFC).  An  example  of  the  reduction  of  a  main- 
system  into  sub-systems  which  are  in  turn  further  detailed  into  smaller  sub-systems  is 
given  below. 

These  diagrams  display  the  reduction  of  the  ENC  into  four  sub-systems,  and  then  the 
further  reduction  of  one  of  these  sub-systems  to  a  level  where  the  output  of  the  sub¬ 
system  may  be  determined,  in  qualitative  terms,  from  the  inputs  to  the  sub-system. 
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Figure  1. 

ENC  reduced  to  subsystems. 
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ENC  sub-system:  Correlation  Cam,  Input  to  Output  relationships. 
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Qualitative  Modelling  of  Component  Interaction. 

To  model  component  interaction  the  allowable  signals  which  could  be  passed  from  one 
component  to  another  were  restricted  to  the  following  terms: 

component  A  requests  an  increase  in  the  parameter  from 
component  B, 

component  A  requests  an  decrease  in  the  parameter  from 
component  B, 

component  A  requests  no  change  in  the  parameter 
from  component  B, 

The  state  of  component  A  has  no  bearing  on  the 
parameter  of  component  B  at  this  point  in  time. 

For  example  consider  the  signal  from  the  ENC  to  the  nozzle  actuators.  This  signal  is  a 
flow  of  fuel  from  the  ENC  to  the  nozzle  actuators  which  moves  the  actuators  in  the 
desired  manner.  However  in  this  case  the  Nozzle  Control  Signal  from  the  ENC  is 
interpreted  into  one  of  the  above  options,  i.e.  when  the  ENC  determines  that  an  increase 
in  nozzle  size  is  required  then  the  Nozzle  Control  Signal  to  the  Nozzle  Actuators  is 
'Increase’. 

Sequencing  of  System  Interactions. 

The  program  developed  for  the  qualitative  model  was  writem  in  Turbo  Pascal.  The  choice 
of  Turbo  Pascal  was  dictated  by  project  time  constraints  and  given  a  more  complex 
modelling  task,  and  more  modelling  resources  the  choice  of  another  language  would  be 
desirable.  Languages  which  would  be  more  appropriate  to  qualitative  modeling  would  be 
C  or  LISP  ,  as  these  languages  would  allow  the  many  concurent  interactions  in  the 
engine  to  be  modelled  in  a  reasonably  natural  fashion.  The  use  of  Turbo  Pascal  however 
dictated  that  the  interactions  between  systems  had  to  be  handled  serially.  This  of  course 
does  not  reflect  what  occurs  in  the  engine.  The  system  interaction  within  the  engine 
occurs  with  much  simultaneous  feedback,  where  the  response  to  an  action  affects  the 
original  ongoing  action  .  In  order  to  simulate  the  true  state  of  affairs  as  acurately  as 
possible  a  sequence  for  main-system  interactions  was  developed.  This  sequence  is 
shown  in  the  figure  below. 


Increase, 

Decrease, 

Null, 

Mu, 
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Figure  3. 

Sequence  of  Main-system  Interactions. 

Adopting  this  sequence  allows  the  action  of  the  major  feedback  routes  in  the  afterburner 
to  be  reproduced  by  the  serial  program. 

Embedding  Faults  and  Outputina  Symptoms. 

The  model  was  developed  to  take  the  inputs  to  the  main-systems  and  develop  the 
outputs,  in  order,  as  required  by  the  sequencing.  This  was  achieved  by  considering  the 
initial  state  of  the  inputs  to  the  subsystems  within  the  first  main-system  (ENC)  and 
propagating  the  resultant  state  change  requests  throughout  the  sub-sysytems  until  the 
required  output  for  the  main-system  had  been  developed.  The  main-system  then  supplies 
the  other  relevant  main-system  (Afterburner  duct)  with  the  input  it  requires.  The  process 
is  then  repeated  until  the  total  sequence  of  main-system  interactions  is  completed.  The 
entire  sequence  is  then  restarted  with  the  new  inputs  which  occurred  as  a  result  of  the 
actions  just  taken.  Thus  the  process  continues  until  the  system's  response  has  evolved. 
This  is  indicated  by  an  absence  of  change  in  the  interaction  parameters,  or  by  the  system 
settling  into  a  repeated  pattern  response. 

In  order  to  keep  track  of  the  system  changes  all  of  the  component  interactions  were 
passed  as  outputs  to  a  file.  This  allowed  the  operation  of  the  model  to  be  examined  in 
detail  This  output  provided  the  behaviour  which  the  simulation  predicted  for  the  input 
and  the  current  state  of  the  entire  system. 

Embedding  faults  then  became  a  matter  of  selecting  a  fault  in  a  component,  and 
determining  how  this  fault  would  affect  the  input-output  relationship  for  that  component 
and  hence  the  relevant  sub-system.  Once  this  had  been  done  the  model  could  be  run  for 
a  variety  of  input  conditions  to  determine  the  modified  behaviour  of  the  faulted  model. 
Identifying  and  interpreting  these  modifications  to  the  model's  behaviour  isolates  the 
symptoms  which  the  model  predicts  to  be  associated  with  the  embedded  fault. 


As  an  example  of  the  operation  of  the  model  the  following  case  provides  the  model's 
reaction  to  a  Power  Lever  Angle  increase.  The  first  output  is  for  a  simulation  with  no 
embedded  fault,  the  second  output  is  for  the  embedded  fault  of  a  malfunctioning  fuel 
metering  valve 

It  can  be  seen  from  the  first  output  that  with  no  fault  the  model  produces  the  normal 
expected  engine  behaviour  in  response  to  a  PLA  increase.  The  nozzle  is  opened  ,  the 
fuel  flow  increases,  and  the  tailpipe  pressure  is  maintained  at  the  desired  level. 

Referring  now  to  the  second  output ,  the  effect  of  the  malfunctioning  fuel  metering  valve 
which  will  not  allow  an  increase  in  fuel  flow  is  shown. 

The  PLA  requests  an  increase  in  the  nozzle  size  and  fuel  flow.  The  nozzle  responds, 
however  the  fuel  flow  cannot.  This  leads  to  a  reduction  in  tailpipe  pressure.  This 
reduction  is  sensed  as  a  turbine  pressure  ratio  error  and  the  nozzle  is  commanded  to 
close  to  counteract  this  problem. This  brings  the  nozzle  position  into  conflict  with  the  PLA 
request,  and  an  unsteady  situai.on  is  created  where  the  nozzle  is  forced  to  fluctuate  in 
response  to  conflicting  requirements. 

Further  examples  which  cover  the  range  of  PLA  and  ENC  trim  inputs  and  the  model’s 
response  with  malfunctioning  metering  valves  ,  and  slipping  nozzle  actuators  are 
included  at  the  end  of  the  appendix. 

Performance  of  the  Qualitative  Fault  Model. 

These  results  provide  symptoms  such  as  fluctuating  nozzle  positions,  decreased  nozzle 
sizes,  and  fluctuating  fuel  flows  which  are  all  possible  and  expected  symptoms  for  the 
embedded  fault  and  the  action  which  the  engine  is  called  upon  to  perform.  As  such  it  is 
considered  that  a  qualitative  fault  model  has  the  potential  to  perform  the  role  of  expert 
system  verifier  and  validator. 
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program  Atterburner(I.E.O); 
t*  Global  declarations  *) 
const 
L  =  14, 

Blank  = ' 

type 

Chng  =  (MU,DEC,NUL,INC); 

Status  = 
record 

CH:  Chng; 

FLT :  Char 
end; 

Data  =  text, 

label  99; 
var 

Pos,J, Count  :  1  ..L; 

Name  :  array[1  ..L]  of  Char; 
change  :  array[1  .3]  of  Char; 

INCORRECTJNPUT_CH,INCORRECTJNPUT_NAME, 
THE_ENDJS_NIEGH  :  Boolean; 

l,E,0  :  Data; 

PLAOLD,PbOLD,Noz_con_sigOLD,R7IOLD,AjiOLD,WfOLD  :  Chng; 

ENC__Trim,PLA,Pb,Fuel_tanks,PbR7i,PbR7R,PbR7, 

Aji.Aj,  PLAN  EW,Noz_con_sig,R7l,R7,  Actuators, Metering_Heads, 
AB_Pump,AB_Pump_Switch,R7_SenseJJne,Wf, Dummy  ;  Status; 

function  CON(Dummy:  Chng)  :String; 
begin 

case  Dummy  of 

DEC  :  CON  :=  'DEC’; 

NUL  ;  CON  :='NUL’; 

INC  :  CON  :=  'INC'; 

MU  :  CON:='MU' 
end; 
end; 

procedure  ENC_NOZZLE(var  Pb,R7l,Aji, 

PLA,  Noz_con_sig,PbR7,PbR7R:  Status); 

(*  Local  declarations  *) 
var 

PbR7l,PLANEW  :  Status; 


begin 

l '  Determine  ENC  Pilot  servo  valve  output  *) 

(*  combine  Aji  &  PLA  to  produce  relative  pilot  valve  origin  PLANEW  *) 
case  Aji.CH  of 

MU  :  PLANEW  CH  :=  PLA.CH; 

DEC  :  case  PLA.CH  of 

MU  :  PLANEW. CH  :=  INC; 

DEC  :  PLANEW.CH  >  NUL; 

NUL  :  PLANEW.CH  :=  INC; 

INC  :  PLANEW.CH  ;=  INC 
end; 

NUL  ;  case  PLA.CH  of 

MU  PLANEW.CH  :=  NUL; 

DEC  :  PLANEW.CH  :=  DEC; 

NUL  :  PLANEW.CH  :=  NUL; 

INC  :  PLANEW.CH  :=  INC 
end; 

INC  ;  case  PLA.CH  of 

MU  PLANEW.CH  :=  DEC; 

DEC  ;  PLANEW.CH  :=  DEC; 

NUL  :  PLANEW.CH  :=  DEC; 

INC  ;  PLANEW.CH  ;=  NUL 
end 

end;(*  case  for  PLANEW  determination  *) 

(*  reset  PLA  to  PLANEW  *) 

PLA.CH  .=  PLANEW.CH; 

(*  determine  PbPt7  for  combination  with  PLANEW  *) 

(*  obtain  PbPt7l  from  Pb  &  Pt7l  *) 
case  Pt7I.CH  of 

MU  ;  case  Pb.CH  of 

MU  :  PbPt7I.CH  :=  MU; 

DEC, NUL, INC  :  PbPt7I.CH  :=  Pb.CH 
end; 

DEC  :  case  Pb.CH  of 

MU  :  PbPt7I.CH  :=  INC; 

DEC  ;  PbPt7I.CH  :=  NUL; 

NUL, INC  ;  PbR7I.CH  :=  INC 
end; 

NUL  :  case  Pb.CH  of 

MU  :  PbPt7I.CH  :=  NUL; 

DEC, NUL, INC  :  PbPt7I.CH  :=  Pb.CH 
end; 

INC  ;  case  Pb.CH  of 

MU  :  PbPt7I.CH  :=  DEC; 

INC  :  PbPt7I.CH  :=  NUL; 

NUL, DEC  .  PbPl7ICH  :«  DEC 
end 

end;(*  case  to  determine  PbPt7I.CH  *) 

Pb  CH>NUL; 

(*  compare  PbPt7l  with  PbPt7R  to  produce  PbPt7*) 
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case  PbPt7l  CH  of 

MU  :  case  PbPt7R.CH  of 

MU.NUL  :  PbPt7.CH  :=  PbPt7R.CH; 

DEC  :  PbR7.CH  :=  INC, 

INC  :  PbPt7.CH  :=  DEC 

end; 

DEC  .  case  PbR7R.CH  of 

MU, NUL, INC  :  PbR7.CH  ;=  DEC; 

DEC  :  PbR7.CH  :=  NUL 

end; 

NUL  :  case  PbR7R.CH  of 

MU.NUL  ;  PbR7.CH  :=  NUL; 

DEC  ;  PbR7.CH  :=  INC; 

INC  :  PbR7.CH  :=  DEC 

end; 

INC  ;  case  PbPt7R.CH  of 

MU, NUL, DEC  :  PbR7.CH  :=  INC; 

INC  :  PbR7.CH  :=  NUL 
end 

end;(*  PbR7  determination  *) 
case  PbR7.CH  of 

DEC  :  PbPt7R,CH  :=  INC; 

INC  :  PbPt7R.CH  ;=  DEC; 

MU.NUL  :  PbPt7R.CH  :=  PbR7.CH 
end;(*  reset  of  requested  PbR7R  *) 

('  Combine  PLANEW  with  PbR7  to  produce  Noz_con_sig 
case  PLANEW.CH  of 

MU  :  case  PbR7,CH  of 

MU  :  Noz_con_sig.CH  ;=  MU; 

DEC  ;  Noz_con_sig.CH  :=  INC; 

NUL  :  Noz_con_sig.CH  :=  NUL; 

INC  :  Noz_con_sig.CH  :=  DEC 
end; 

DEC  :  case  PbR7.CH  of 

NUL, MU, INC  :  Noz_con_sig.CH  :=  DEC; 

DEC  :  Noz_con_sig.CH  :=  NUL 
end; 

NUL  :  case  PbR7.CH  of 

MU.NUL  .  Noz_con_sig.CH  :=  NUL; 

DEC  ;  Noz_con_sig.CH  :=  INC; 

INC  :  Noz_con_sig.CH  :=  DEC 
end; 

INC  .  case  PbR7.CH  of 

MU, NUL, DEC  :  Noz_con_sig.CH  :=  INC; 

INC  ;  Noz_con_sig.CH  >  NUL 
end 

end  (*  determination  of  Noz_con_sig  *) 
end;  (*  ENC_NOZZLE  *) 
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procedure  NOZZLE(Noz_con_sig  Status; 

var  Actuators.  Aji.Aj  Status) ; 

; '  local  declarations  *) 
begin 

(*  Determine  effect  of  signal  from  Nozzle  controller  to  actuators  *) 
case  Actuators. FLT  of 
("O'  =  operational  *) 

O'  :  Actuators. CH  :=  Noz_con_sig  CH; 

("S'  =  slipping  actuator  *) 

S'  :  case  Noz_con_sig.CH  of 

MU, NUL, INC  :  Actuators.CH  :=  INC; 

DEC  ;  Actuators  CH  :=  DEC 
end 

end, 

(*  Determine  effect  of  Actuators  on  Aj*) 

Aj.CH  :=  Actuators.CH; 

(*  Determine  effect  of  Aj  on  Aji  *) 

Aji.CH  :=  Aj.CH 

end, (‘NOZZLE*) 


procedure  ENC_ABFC(Aji,PbR7:status; 

var  Wf:Status); 

(*  local  declarations  *) 
var 

WfR  Status; 
begin 

(*  Determine  Wf  request  from  Aji  &  PbPt7  *) 
case  Aji.CH  of 

MU  :  WfR.CH  ;=  PbPt7.CH; 

NUL  ;  case  PbPt7.CH  of 

MU  ;  WfR.CH  :«  NUL; 

DEC, NUL, INC  .  WfR.CH  :=  PbPt7.CH 
end; 

DEC  ;  case  PbPt7.CH  of 

MU.NUL  :  WfR.CH  ;=  Aji.CH; 

DEC  :  WfR.CH  :=  DEC; 

INC  WfR.CH  :=  NUL 
end; 

INC  ;  case  PbPt7.CH  of 

MU.NUL  :  WfR.CH  :=  INC; 

DEC  :  WfR.CH  :=  NUL; 

INC  :  WfR.CH  INC 
end 

end, (‘determination  of  WfR*) 
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i*  Determine  Wf  from  WfR  effect  on  ABFC  *) 
case  Metering  Heads  FLT  of 
’O'  Wf  CH  =  WfR  CH  ; 

B'  case  WfR  CH  of 

DEC. MU  Wf  CH  =DEC, 
NUL.INC.  Wf.CH  =NUL 
end 

end; 


end;(*  ENC_ABFC  *) 

procedure  DUCT(Wf,A|  Status; 

var  Pt7l,Pt7  Status); 

(*  local  declarations  *) 

begin 

(*  Determine  Pt7  from  Aj  &  Wf  *) 
case  A|  CH  of 

NUL.MU  Pt7  CH  ;=  Wf  CH, 

DEC  case  Wf  CH  of 
INC, NUL.MU  Pt7  CH  :=  INC; 
DEC  Pt7  CH  :=  NUL 
end; 

INC  case  Wf  CH  of 
DEC, NUL, MU  :  R7  CH  ;=  DEC; 
INC  Pt7  CH  =  NUL 
end 

end;(*  determination  of  Pt7  *) 

(*  determine  R7I  from  Pt7  *) 

Pt7l  CH  =  R7  CH 
end;(*  DUCT  *) 

begin 


(*  Initialise  components  to  MU  state  *) 
ENCJnm.CH  -  MU, 

PLA.CH  MU; 

Pb  CH  -  MU; 

Fueljanks.CH  =  MU; 

PbPt7l  CH  =  MU, 

PbPt7R.CH  ;-  MU; 

PbR7  CH  MU; 

A|i  CH  =  MU, 

A|  CH  ;=  MU, 

PLANEW  CH  =  MU; 
Noz_con_sig.CH  :»  MU; 

R7I.CH  MU; 

R7  CH  ;-  MU; 

Actuators  CH  »  MU, 

Actuators  FLT  -  S', 
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('  insert  fault  *) 

Metering  Heads  CH  .=  MU; 

AB  Pump  CH  =  MU. 

AB  Pump  Switch  CH  :=  MU 
Pt7_Sense_Lme.CH  =  MU; 

Wf.CH  -  MU; 

(*  assign  files  *) 

Assign(  I,  'SystemJ  PAS'); 

Assign(  E,  'System_E.PAS'); 

Assign(  O,  ’System_0  PAS'); 

(*  Reset  input  files  *) 

Reset  (I); 

Reset  (E); 

Rewrite  (O); 

wnteln(0,'ENC  PLA  Pb  Pb/Pt7  Aji  Aj  Noz  Pt7l  Pt7  Actu  Wf); 
writeln(0,'Trim  sig  ator  '); 

INCORRECT_INPUT_CH  :=  false; 

(*  read  &  convert  inputs  &  errors  to  internal  type  *) 

while  not  EOF(I)  do 

begin 

for  Pos  :=  1  to  L  do 
begin 

if  EOLn(l)  then 
Name[Pos]  =  Blank 
else 
begin 

Read(l,Name[Pos]'; 

writeln('NamePos',Pos,Name[Posj) 

end 

end; 

Readln(l); 
for  Pos  :=  1  to  3  do 
begin 

if  EOLn(l)  then 
Change[Pos]  ;=  Blank 
else 
begin 

Read(l, Chang  e{Pos]); 
writeln('ChangePos',Pos,Change[Pos]) 
end 
end; 

Readln(l); 

Readln; 

if  Change[1]=  Tthen 
begin 
writeln(T); 

Dummy  CH  =INC 
end  ; 

(*  end*) 

if  Change(  1]=  N'then 
begin 

writeln('N'); 
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Dummy  CH  =NUL 
end  ; 

if  Change[l]=  'D'then 
begin 

writeln('D'); 

Dummy. CH  =DEC 
end  ; 

INCORRECT_INPUT_NAME  ;=  False; 

if  Name  =  'ENC_Tnm  'then  ENC_Trim.CH  :=  Dummy. CH; 

If  Name  =  'PLA  'then  PLA.CH  ;=  Dummy. CH; 

if  Name  =  Pb  'then  Pb.CH  :=  Dummy. CH; 

if  Name  =  'Fueljanks  'then  Fueljanks. CH  :=  Dummy. CH; 

if  Name  =  'PbR7l  'then  PbPt7I.CH  ;=  Dummy. CH; 

if  Name  =  'PbPt7R  'then  PbR7R  CH  :=  Dummy  CH; 

if  Name  =  'PbPt7  'then  PbR7.CH  :=  Dummy. CH, 

if  Name  =  Aji  then  Aji.CH  :=  Dummy  CH; 

if  Name  =  'Aj  'then  Aj.CH  ;=  Dummy. CH; 

if  Name  =  'PLANEW  then  PLANEW  CH  :=  Dummy. CH; 

if  Name  =  'Noz_con_sig  then  Noz_con_sig.CH  :=  Dummy. CH; 

if  Name  =  R7I  then  R7I  CH  ;=  Dummy.CH; 

if  Name  =  'Pt7  then  Pt7.CH  :=  Dummy.CH; 

if  Name  =  'Actuators  then  Actuators. CH  :=  Dummy.CH; 

if  Name  =  MetermgHeads'then  Metering_Heads.CH  :=  Dummy  CH; 

if  Name  =  AB_Pump  'then  AB_Pump.CH  :=  Dummy.CH; 

if  Name  =  AB_Pump_Switch'then  AB_Pump_Switch.CH  :=  Dummy.CH; 

if  Name  =  Pt7_Sense_Lme'then  Pt7_Sense_Line.CH  ;=  Dummy.CH; 

if  Name  =  Wf  'then  Wf  CH  :=  Dummy.CH; 

end. 

while  not  EOF(E)  do 
begin 

for  Pos  :=  1  to  L  do 
begin 

if  EOln(E)  then 
Name{Pos]  :=  Blank 
else 
begin 

Read(E,Name[Pos]); 

writeln('NamePos',Pos,NamelPos]) 

end 

end; 

Readln(E); 

Readln(E,  Dummy.  FLT); 
writelnfDummy  fit  '.Dummy. FLT); 
readln; 

if  Name  *  ENC_Trim  'then  ENC_Trim.FLT  >  Dummy. FLT; 
if  Name  *  PLA  'then  PLA. FLT  ;*>  Dummy. FLT; 
if  Name  *  'Pb  'then  Pb.FLT  >  Dummy. FLT; 
if  Name  *  ’Fueljanks  'then  Fueljanks. FLT  >  Dummy. FLT; 
if  Name  -  'PbPt7l  'then  PbR7l,FLT  :=  Dummy. FLT; 
if  Name  -  'PbPt7R  'then  PbR7R.FLT  >  Dummy. FLT; 
if  Name  *  'PbR7  'then  PbR7.FLT  ;=  Dummy. FLT; 
if  Name  *  Aji  'then  Aji. FLT  >  Dummy.FLT; 
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if  Name  =  Aj  'then  Aj.FLT  :=  Dummy. FLT; 

if  Name  =  'PLANEW  'then  PLANEW  FLT  :=  Dummy. FLT; 

if  Name  =  Noz_con_sig  'then  Noz_con_sig. FLT  :=  Dummy. FLT, 

if  Name  =  Pt7l  'then  R7I.FLT  ;=  Dummy. FLT; 

if  Name  =  ‘Pt7  'then  Pt7.FLT  ;=  Dummy. FLT; 

if  Name  =  'Actuators  'then  Actuators. FLT  :=  Dummy. FLT; 

if  Name  =  'MeteringHeads'then  Metering_Heads.FLT  :=  Dummy. FLT; 

if  Name  =  ‘AB_Pump  'then  AB_Pump. FLT  :=  Dummy. FLT; 

if  Name  =  'AB_Pump_Switch'then  AB_Pump_Switch.FLT  :=  Dummy. FLT; 

if  Name  =  ’Pt7_Sense_Line'then  Pt7_Sense_Line.FLT  ;=  Dummy. FLT; 

if  Name  =  ’Wf  ’then  Wf.FLT  :=  Dummy. FLT; 

writelnfActuator  fit',  Actuators. FLT); 

end; 

PbPt7R.CH:=ENC_Trim.CH; 

THE_END_IS_NIEGH  :=  False; 

(*  Evolve  system  response  to  the  conditions  *) 

while  ('system  response  evolving*)Not(THE_END_IS_NIEGH)  do 
begin 

(*  ENC  acts  on  current  system  state  to  send  nozzle  control  signal  *) 
ENC_NOZZLE(Pb,Pt7l,Aji, 

PLA,Noz_con_sig,PbPt7,PbPt7R); 

(*  Nozzle  responds  and  provides  ENC  with  feedback  *) 
NOZZLE(Noz__con_sig,  Actuators,  Aji.Aj); 

('  ENC  combines  all  information  and  sends  a  signal  to  ABFC  *) 
ENC_ABFC(Aji,PbPt7,Wf); 

('  Duct  adjusts  to  current  nozzle  and  Wf  inputs  *) 

DUCT(Wf,Aj,Pt7l,Pt7); 

('  check  evolution  of  system  *) 
case  PLA.CH  of 
NUL  ;  case  Pb.CH  of 

NUL  .  case  Noz_con_sig.CH  of 
NUL  case  Pt7I.CH  of 
NUL  ;  case  Aji.CH  of 
NUL  :  case  Wf.CH  of 

NUL  :THE_END_IS_NIEGH  True; 

MU, DEC, INC  :THE_END_IS_NIEGH  :=  False 
end; 

MU, DEC, INC  ;THE_END_IS_NIEGH  ;=  False 
end; 

MU, DEC, INC  :THE_END_IS_NIEGH  >  False 
end; 

MU, DEC, INC  :THE_END_IS_NIEGH  >  False 
end, 

MU, DEC, INC  :THE_END_IS_NIEGH  :=  False 
end; 

MU, DEC, INC  :THE_END_IS_NIEGH  >  False 
end; 
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if  Not(THE_ENDJS_NIEGH)  then 
begin 
Count:  =  1 ; 

if(  (PLA.CHj  =  (PLAOLD))  then  Count:=Count+1 , 

it((  Pb.CH)  =  (PbOLD))  then  Count:=Count+1 ; 

if((  Noz_con_sig.CH)  =  (Noz_con_sigOLD))  then  Count:=Count+1 ; 

if(  (Pt7I.CH)  =(  R7IOLD))  then  Count:=Count+1 ; 

if((  Aji.CH)  =(  AjiOLD))  then  Count  :=Count+1; 

if(  (Wf.CH)  =  (WfOLD))  then  Count:=Count+1; 

if(  Count  =  7)  then  THE_END_IS_NIEGH  :=  True  ; 

(*  output  current  system  state  *) 

writeln(0,CON(  ENC_Trim.CH):3,CON(  PLA.CH  ):4,CON(  Pb.CH  ):4, 
CON(  PbR7.CH  ):4.CON(  Aji.CH  ):6.CON(  Aj.CH  ):4, 

CON(  Noz_con_sig.CH):4,CON(  R7I.CH  ):5,CON(  Pt7.CH  ):4. 
CON(  Actuators. CH):5,CON(  Wf.CH):4); 
it  J  =10  then  THE_END_lS_NIEGH  :=  True; 

J:=J+1 ; 

PLAOLD:=PLA.CH; 

PbOLD:=Pb.CH; 

Noz_con_sigOLD:=Noz_con_sig.CH; 

R7IOLD:=Pt7I.CH; 

AjiOLD:=Aji.CH; 

WfOLD:=Wf.CH; 

end; 

end; 

99: 

if  INCORRECTJNPUT_CH  then 

write(0,'*********lncorrect  change  parameter  entered.*********'); 

if  INCORRECT_INPUT_NAME  then 

begin 

writeln(O); 

writefO,' . ***lncorrect  object  name  entered.*********'); 

writeln(O) 

end; 

(*  Output  final  system  state  in  full  *) 

writeln(0,CON(  ENC_Trim.CH):3,CON(  PLA.CH  ):4,CON(  Pb.CH  ):4, 
CON(  PbR7.CH  ):4,CON(  Aji.CH  ):6,CON(  Aj.CH  );4, 

CON(  Noz_con_sig.CH);4,CON(  R7I.CH  );5,CON(  R7.CH  ):4, 
CON(  Actuators. CH):5,CON(  Wf.CH):4); 

close(l); 

close(E); 

close(O) 

end.  (*  Afterburner  *) 
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